EBS でボリュームサイズ/タイプ変更時のパフォーマンスを検証してみた

EBS でボリュームサイズ/タイプ変更時のパフォーマンスを検証してみた

Clock Icon2017.02.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、菊池です。

今週発表されたアップデートにより、EC2にアタッチされたEBSがオンラインでサイズ/タイプの変更が可能になりました。

はじめに

これまで、容量や性能の不足で悩んでいた方には嬉しいアップデートですね!本番環境での移行を検討されている場合には、まず以下のドキュメントをみて、注意事項をよく理解した上で実施するのがいいでしょう。

ドキュメントによると以下の点に注意が必要です。

  • ボリュームのデタッチまたはインスタンスの停止が必要なケースがある
    • 変更時にエラーメッセージが表示された場合
    • 旧世代のインスタンスにアタッチされたボリューム
  • 旧世代のマグネティックボリュームでは変更がサポートされない
  • 一度変更した後、同じボリュームは6時間は変更ができない

また、オンラインで変更するにあたり、以下の点も気になるかと思います。

  • 変更時にパフォーマンスの劣化などがないか
  • 変更後、どの程度の時間でパフォーマンスが変化するか

という訳で、変更タイミングでのパフォーマンスがどのように推移するか検証しましたので紹介します。

検証内容

EC2にアタッチしたEBSにI/Oをかけ続けた状態で、パフォーマンスを計測します。

検証環境

  • 利用したAMI:Amazon Linux AMI 2016.09.1 (HVM), SSD Volume Type
  • インスタンスタイプ:c4.large(EBS最適化)
  • ファイルシステム:ext4
  • EBSはルートボリュームではなく、追加アタッチしたボリュームで実施

検証方法

fioでランダムWriteを継続している状態で、1秒ごとにiostatの値を取得

fioコマンド

# fio -filename=/data/testfio.file -direct=1 -ioengine=libaio -rw=randwrite -bs=16k -size=12G -group_reporting -name=randread -numjobs=64 -runtime=18000

iostatコマンド

# iostat -xnc 1

検証シナリオ

上記のI/O負荷が発生している状態で、以下の3つのケースで測定

  1. GP2(汎用SSD):100GB でクレジット枯渇後、容量を250GBに拡張
  2. GP2:250GB から ST1(スループット最適化):500GBに変更
  3. GP2:100GB から IO1(プロビジョンドIOPS)/4000IOPSに変更

いずれも、EBSの拡張/変更のみでファイルシステムの拡張は実施していません。

検証結果

1. GP2容量拡張

ebs_modify_001

バースト状態の3000 IOPSから、100GBのベースラインである300 IOPSに低下した後、ボリュームサイズを250GBに変更しました。変更実行後、およそ10秒程度で再びバースト状態のパフォーマンスが発揮されるようになりました。

また、変更後に約2400秒間、バーストパフォーマンスが継続しました。これは、250GBのボリュームでの最大バースト時間と一致します。

つまり、容量変更によってクレジットが100%まで回復していると推測できます。この時のCloudwatch上のバーストバランスの推移は以下のようになりました。5分間隔のプロットの間なので正確ではないですが、クレジットも回復していることが確認できます。

ebs_modify_004

2. GP2 -> ST1

ebs_modify_002

バースト中にHDDのボリュームであるST1に変更しました。こちらも変更実行後10秒程度で新しいボリュームタイプのパフォーマンスに変化しました。

3. GP2 -> IO1(4000IOPS)

ebs_modify_003

このケースではクレジット枯渇後にIO1に変更しています。このケースでも変更実行後10秒程度でパフォーマンスが変更されました。

まとめ

今回の検証から以下のことがわかりました。

  • 容量/タイプ変更に伴うパフォーマンスの劣化はない
    • ただし、ファイルシステム変更を実施する場合は別途検証が必要です
  • 変更に伴うパフォーマンスの変化は10秒程度で適用される
  • GP2で変更を実施した場合、バーストクレジットは最大まで回復する

パフォーマンス劣化がないことやクレジットの回復はありがたいですね。急激な負荷がかかりパフォーマンスの追加が必要な時には有効な手段となりそうです。

ただし、一度変更した場合には次の変更まで6時間以上空ける必要があることには注意が必要です。6時間経過前に変更しようとするとエラーとなって変更できませんでした。

ebs_modify_005

あくまでも計画的に変更・拡張を実施するのがよいでしょう。

 

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.